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(54) Titie: MEDICINAL FLUID PUMP HAVING MULTIPLE STORED PROTOCOLS 
(57) Abstract 

A pump (23) used to infuse a fluid into a patient (27) is 
contixrfled in accordance with a plurality of parameters entmd 
by an operator. These parameters defii» a protocol that is 
applied in controlling the qpcradon of die punop to determine 
the rate, volume, and timing of the fluid infusion. The operat(»r 
enters the parameters using a keypad (16) in response to prompts 
provided on a display (18). Once the parameters for a current 
protocol are entered, they can be stored as a speed protocol by 
selecting that option from a menu appearing on the display. Up 
to three speed protocols can be stored in memory in the disclosed 
preferred embodiment When preparing to infuse a medicinal 
fluid, an operator can elect to enter a new protocol or to select an 
apim>priate speed protocol stored in monory for loading as die 
current protocol. Use of stored speed protocols saves time and 
reduces die likelihood of errors duit can occur when data defining 
die parameters controlling the infusion process are entered by an 
operator. 
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MEDICINAL FLUID PUMP HAVING MULTIPLE STORED PROTOCOLS 

Field of the Invention 
The present invention generally pertains to a pump for iniusing medicinal 
liquids into a patient, and more specifically, to a pimip that is controlled in 
5 accordance with a plurality of parameters that are entered by an operator. 

Backgroimd of the Invention 
Cassette, peristaltic, and other types of motor or solenoid driven pimips are 
widely employed to infuse medicinal fluids into the cardiovascular systems of 
patients. These pumps often include a controller that determines the rate at which 
10 the medication is infused, the volume or dosage of medicinal fluid administered, 
whether it is delivered as a bolus or continuous mfusion, the time that the 
administration occurs, and/or the interval of time that the pump will operate. These 
parameters and others are usually entered into an electronic memory for the pump 
controller via a user interface control panel on the pump by medical personnel, 
15 based upon the type and concentration of the drug being administered, and patient 
specific data, such as the patient's weight, age, gender, and medical condition. 
Although entry of the parameters that control the pump's operation may be 
relatively straightforward, several minutes may be required to specify all of the data 
required to define a drug delivery protocol. More importantly, each time that a 
20 pump is programmed to administer a specific medicinal fluid, there is a risk that 
human error may cause improper values for the parameters to be entered. 

To avoid the potential risks involved in programming a pump each time it is 
used to deliver a different type of medication, it is not uncommon for hospitals and other 
medical facilities to purchase and employ multiple pumps, with each ptimp programmed 
25 to administer a particular type of drag in a defined manner. Any 
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programming required to tailor the administration of a drug to a patient is thereby 
minimized by using a separate pump for each type of drug and delivery protocol 
commonly required. Thus, one ptunp will be used to administer a certain pain 
management dmg, and a different pump will be programmed to continuously 

5 administer a saline/glucose fluid. The only changes required for a use of a pump 
with each patient receiving the same type of medicinal fluid may be the entry of one 
or more patient dependent parameters, such as the total drug volume to be 
delivered. Alternatively, if a single pump of the conventional type is used to 
administer different drugs involving totally different protocols, a medical 

10 practitioner trained to program the pump must be available each time that it is used 
to infuse a different drag. A medical facility must therefore either maintain a pump 
programmed for each drag typically infused or must ensure that properly trained 
personnel arc always available to reprogram a pump each time that it is used to 
administer a different drag. However, the latter solution to this problem increases 

15 the risk that a life-threatening error might occur when the pmnp is reprogrammed 
and requires that properly trained personnel always be available to reprogram the 
piunps that are used. 

Clearly, it would be desirable if a piunp could be used to administer 
different types of medicinal fluids without the need for manual reprogramming each 

20 time that the type of medicinal fluid infused is changed. In U.S. Patent 
No. 4,676,776, a system is disclosed that includes a delivery unit, which is remotely 
coupled to a programming imit through a telephone line and modem. Alternatively, 
the system will accept a programmable logic cartridge that is programmed by the 
programming xmit and hand-cairied to the pump. The remote programming unit 

25 includes an operationally independent computer that manages the protocols for 
operating the fluid delivery unit. The computer of the programming unit has access 
to a number of both predefined and operator programmed protocols that are stored 
in a database integral within its memor>\ The delivery unit does not require a 
microprocessor to define the protocol for delivering a fluid, since all of the 

30 operational parameters are set by the remote computer in the programming unit. 
Each time that the delivery unit is to be used to administer a different drag, the 
appropriate predefmed or operator defined protocol for that drag is downloaded 
from the remote computer into a control and logic module of the delivery unit. 
However, only one protocol at a time can be loaded into the delivery unit. Either 

35 the telephone/modem interconnection or a programmable logic cartridge suitably 
programmed for the correct drag must be used lo transfer the protocol that will be 
employed from the remote computer into the delivery unit. 
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The requirement for transferring the protocol from the remote computer to 
the delivery unit represents a significant drawback to this prior art infiision system, 
since it is often not convenient to physically transport a programmable logic 
cartridge between a remote computer and the delivery unit or to arrange for a 
5 modem and telephone line intercoimection between the computer in the 
programming unit and the logic module of the delivery unit. The patent specifically 
teaches that it is advantageous to employ a remote computer for defining the 
protocol because microprocessors used to control piunps are subject to possibly 
undetected failures and have limited processing capability. 

10 Other types of conventional pumps include multiple channels, each channel 

being capable of infusing a different type of drug into a patient according to a 
different delivery protocol. However, even these pimips do not enable the operator 
to select between different previously stored protocols for the administration of a 
medicinal fluid on a single channel. Accordingly, each time that a channel is used 

1 5 to deliver a different type of drug than that previously administered, the protocol for 
the new drug must be reentered into the pump for that channel. 

None of the prior art pumps for administering drugs via a specific channel 
allow an operator to store protocols for different drugs integrally within the pump. 
Integral storage of the different protocols within the pump is important to obviate 

20 the need to transfer a selected protocol &om a remote computer, and more 
importantly, to avoid the cost of a separate computer in which such protocols are 
stored in a database. 

Simunarv of the Invention 
In accordance with the present invention, a pump is defined for 

25 administering a fluid to a patient. The pump includes a fluid drive unit that is 
adapted to coiq}le with a fluid line and to force fluid from a source to the patient 
through the fluid line. A control is coupled to the fluid drive unit to control its 
operation. Also provided is a memory in which a plurality of protocols are stored. 
These protocols each specify at least one parameter that is used to control the fluid 

30 drive. A user interface that is integral with the pump and is coupled to the control 
and to the memory enables the operator to enter at least one parameter for any of the 
pluralit}' of protocols. With the user interface, one of the protocols can be selected 
for use by the control in actively controlling the operation of the drive imit so as to 
administer the fluid to the patient. 

35 Preferably, the parameter entered by the operator includes one of a 

continuous fluid flow, an intermittent fluid flow, and a bolus fluid flow. It can also 
include one of a rate of fluid flow, a volume of fluid flow, a time of fluid flow, and a 
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duration of fluid flow. In addition, the parameter may comprise a varying rate of 
fluid flow. 

The user interface enables the operator to define a current protocol and to 
store the current protocol as one of the plurality of protocols in the memory. The 
5 control cooperates with the user interfece to enable the operator to review one of the 
plurality of protocols stored in the memory while the drive unit is being operated in 
accordance with a different one of the plurality of protocols. Furthermore, the user 
interface enables the operator to recall one of the plurality of protocols from 
memory so that it can be employed as a currently active protocol used by the 
10 control in controlling the drive unit. In addition, the user interface enables the 
operator to modify the currently active protocol prior to storing it in the memory. 
Since the plurality of protocols are integrally stored in memory, a change in the 
drug that is to be delivered is readily accommodated simply by recalling the 
protocol from memory that is appropriate for administering the drug. In most cases, 
1 5 there is no need to completely redefine the protocol that must be used each time that 
the pump is employed to administer a different drug. 

Brief Description of the Drawing Figures 
The foregoing aspects and many of the attendant advantages of this 
invention will become more readily appreciated as the same becomes better 
20 understood by reference to the following detailed description, when taken in 
conjunction with the accompanying drawings, wherein: 

FIGURE 1 is a schematic block diagram of a controller for a pump 
embodying the present invention; 

FIGURE 2 is a front elevational view of the pump of FIGURE 1 ; 
25 FIGURE 3 is a flow chart showing the steps for operating the pump without 

use of a speed protocol; 

FIGURE 4 is a flow chart illustrating the logic involved in operating the 

pump using speed protocols; 

FIGURE 5 is a flow chart showing the logical steps for assigning a new 

30 speed protocol; 

FIGURE 6 is a flow chart showing the logical steps for recalling a speed 

protocol that is stored in memor>" 

FIGURE 7 is a flow chart illustrating the steps for deleting a speed protocol 
from among those stored in memory; 
35 FIGURE 8 is a flow chart showing the steps involved in reviewing a speed 

protocol; and 
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FIGURE 9 is a flow chart showing the steps involved in printing a speed 
protocol. 

Description of the Preferred Embodiment 
With reference to FIGURE 1, a block diagram illustrates the components 
S comprising a control 10 for an integral pump 23 that is used for iniusing medicinal 
fluids fix)m a source 25 into a patient 27 in accordance with the present invention. 
While the preferred embodiment of this pump forces fluid to flow through a tube set 
(not shown) using a peristaltic pump 23, it will be appaxent from the following 
description that other types of pumping apparatus (such as a cassette pump) could also 

10 unplement the present invention, thereby providing the benefits of accessing stored 
protocols when the pump is used to deliver different drugs or medicinal fluids. 

Control 10 includes a microprocessor 12, ^ch implements the primary 
control functions required to operate pmnp 23. These functions are defined by a set 
of program steps that are stored within a read only memory (ROM) 38. The 

1 S program steps stored in ROM 38 are in the form of a binary code, which is executed 
by microprocessor 12 to control the operation of various components of the pump 
following an operator defined protocol. To improve safety and reduce the number 
of single point failures, a redundant safety microprocessor 14 is included. Safety 
microprocessor 14 includes internal ROM and random access memory (RAM). In 

20 the preferred embodiment, a Motorola Corporation Model MC68L1 IKl integrated 
circuit is used for microprocessor 12, and a Motorola Corporation 
Type MC68HC705C8 integrated circuit is used for safety microprocessor 14, The 
preferred embodiment employs an integrated circuit for ROM 38 that has a capacity 
to store up to 256 Kbytes of program steps and control data. In addition, an 

25 external integrated circuit RAM 37 with a capacity of 32 Kbytes is coupled to 
microprocessor 12 to provide storage for data and variables. Data stored within 
RAM 37 is maintained so long as electrical power is supplied to it. Electrical 
power is supplied to the pump from either an AC line power supply or a battery 
pack (conventional or rechargeable), as indicated by AC and battery power 

30 supply 39. When both the AC and nomial battery power supply is interrupted a 
backup (lithium) battery (not separately shown) provides power to the control 
circuitr>\ Thus, even when pump 23 is not operating, the data stored within the 
RAM are retained. 

Safety microprocessor 14 is responsible for reading data input by an 
35 operator on a keypad 16, monitoring motor speed, and providing data access through 
an RS-232 serial port (not shown). Using the keypad, the operator can specify 
parameters such as the percentage of volume, the rate, and/or the volume that will be 
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used for administering a particular medicinal fluid. Microprocessor 12 is coupled to 
safety microprocessor 14 to receive these data for presentation to the operator on a 
display panel 18, which is directly coupled to microprocessor 12. 

Operation of pump 23 is controlled by microprocessor 12 with signals that 

5 are input to a speed control and switch off circuit 20. This circuit is connected to a 
DC motor 22 to control its rate of rotation. Since the preferred embodiment of the 
presoit invention pimips fluid using a peristaltic cassette, the rate at which fluid is 
administered to a patient is directly proportional to the rate at which DC motor 22 
rotates. It will thus be iq)parent that speed control 20 is used for controlling DC 

10 motor 22 to achieve the desired rate for infusing fluid into the patient. DC motor 22 
includes a Hall effect magnetic pickup (not separately shown) that produces 
rotational rate signals, which are applied as an input signal to an encoder 24. 
Encoder 24 processes this input signal, producing a corresponding digital signal 
"01" indicating the rate of rotation in the clockwise (CW) direction or a 

15 corresponding digital signal "02" indicating the rate of rotation in the 
counterclockwise (CCW) direction. The digital signal corresponding to the rate of 
rotation in the CW direction is input to both a direction flip flop circuit 26 and to 
safety microprocessor 14, while the digital signal indicative of the rate of rotation in 
the CCW direction is input only to direction flip flop 26. 

20 In normal operation, the DC motor and the pump rotate in a CW direction. 

The DC motor has an attached gearbox (not separately shown), but the encoder 
indicates shaft revolutions of the DC motor ahead of the gearbox - not at the 
gearbox output shaft Slight rotation of the DC motor in the CCW direction can 
occur due to gearbox "wind-up," especially when the DC motor is turned off and 

25 comes to a stop. When the DC motor is again energized, it turns a few degrees 
before the output shaft actually starts turning. There will thus be "extra" encoder 
pulses produced that do not accurately account for output gearbox shaft revolutions. 
On the average, the number of extta CW pulses produced when the DC motor starts 
will be equal to the number of CCW pulses produced when the DC motor stops. If 

30 the number of CCW pulses is subtracted from the total CW pulses, the error in the 
total CW pulses is corrected, thereby improving flow rate accuracy. This accuracy 
improvement is significant at low flow rates (less than 1 cc/hr). 

Certain fault conditions, such as an empty fluid source container, can cause 
microprocessor 12 to stop the DC motor. Safety microprocessor 14 can also issue a 

35 switch off command to DC motor 22 if it detects that the pump is operating 
abnormally or requires operator intervention to correct a problem. 
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To enable control 10 to properly control the rate of rotation of DC motor 22, 
a motor current sensing circuit 28 provides a current feedback signal to 
microprocessor 12 and to the speed control. Sinularly, a motor voltage sensing 
circuit 30 provides another feedback signal indicative of the voltage across the 
S windings of the DC motor to microprocessor 12 and to the speed control. These 
two feedbac}c signals and control signals supplied by microprocessor 12 are 
employed by speed control and switch off circuit 20 to set and maintain the average 
rotational speed of DC motor 22 to achieve the desired drog infusion rate. 

Either microprocessor 12 or safety microprocessor 14 will respond to 

10 conditions requiring operator intervention by activating an audible alarm drive 
circuit 32. The audible alarm drive circuit produces a drive signal that is applied to 
an audible alarm 34, causing it to produce a distinctive alarm sound that is used to 
attract the attention of the operator. Upon hearing the audible alarm sound, the 
operator knows to check the pump to determine the appropriate corrective action 

15 that must be taken. For example, an air-in-line sensor (not shown) monitors the 
infusion line to detect air bubbles. If air bubbles larger than a predefined size are 
detected in the infusion line, the air-in-line sensor produces a signal to which 
microprocessor 12 will respond by stopping the DC motor and activating the 
audible alarm. 

20 A reset circuit 36 serves as an internal watchdog by checking the software 

strobing rate on microprocessor 12. If software strobing (a timing signal indicative 
of the rate at which the microprocessor is executing machine instructions) is not 
within a predefined range, the reset circuit issues a reset command to both 
microprocessor 12 and safety microprocessor 14. 

25 Referring now to FIGURE 2, the user interface, which appears on the front 

of a pump 50, includes a lower keypad section 16a, an upper keypad section 16b, 
and a display 1 8, which is disposed above the upper keypad section. Lower keypad 
section 1 6a includes 1 8 keys arranged in an array of three columns and six rows. In 
addition to the conventional nimieric keys 0 through 9, lower keypad 16a includes 

30 several special purpose keys. A "PRIME" key 52 is depressed by the operator to 
manually energize the pump in order to prime and clear air from the iniusion line 
before it is connected to the patient's body. A key 54 labeled "NO" is depressed to 
enter a negative response to questions that appear on display 18. Conversely, a 
key 56 labeled "YES/ENTER'' is provided to enable the operator to respond in the 

35 affirmative to questions appearing on display 18 and to register a niuneric entry or 
to advance to the next display screen when entering data. A key 58 labeled 
"BACKUP" is used to exit a history or a Help display. In addition, key 58 is used to 
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access previous steps that were entered by the operator when programming the 
control for a new protocol. Furthermore, the BACKUP key is used for exiting 
"CHANGE" and "OPTIONS" modes. 

A key 60, which is labeled "CHANGE," is used to correct an entry when 
5 entering data, for reviewing a program, when changing containers, to enter a new 
program, and to change a therapy. A "SILENCE" key 62 temporarily silences 
audible alarm 34 (shown in FIGURE 1), enabling the operator to correct the 
condition that initially caused the alarm without the annoyance of the audible signal 
continuing. 

10 A comUned upwardly pointing arrow and a period tqipear on a key 66. 

Similarly, a downwardly pointing arrow appears on a key 64. The up and down 
arrow keys are used for scrolling through menu selections and through the history 
of drug infusion that can be selectively provided on display 18. In addition, these 
two keys are used for scrolling through input selections when entering an infusion 

1 5 protocol. Key 66 is also used for entering a decimal point in numeric data. 

In upper keypad 16b, an "OPTIONS" key 68 can be depressed to selectively 
review a protocol, display, print or clear a drug infusion history for a patient, 
selectively lock or unlock the keypad, set the air-in-line alarm, set an intemal clock 
used by control 10, access speed protocols, adjust screen contrast and sound level, 

20 and to display an alarm log. A hexagonal-shaped key 70, which is labeled "STOP," 
is provided to enable the operator to selectively stop an infusion at any time. 
Similarly, a key 72 labeled "START' is provided to enable the operator to start the 
infusion. As already noted, the operator can access a help screen at any time by 
depressing key 74. 

25 In the lower portion of display 18 is included a bell-shaped visual signal 

(light emitting diode (LED)) 75, which is lighted when an alarm condition occurs. 
Another visual signal 76 is lighted when the pump is powered using AC line power 
(instead of the intemal power pack batteries). 

On the top surface of the pump is disposed a bolus switch 77, which the 

30 operator can depress to manually deliver a bolus of the drug currently being infused 
if the pump is programmed to do so. A jack 79 is provided on the left upper side of 
the pump to accept a lead from a remote bolus switch (not shown). This remote 
bolus switch can be activated by the patient when the pump is being used to deliver 
a pain management drug or for variable time drug infusions (if programmed). Also 

35 disposed on the left upper side of the pump is a fitting 78 to which an AC line cord 
(not shown) can be coupled, and a slide switch 81 that is used for turning the pump 
off and on. 
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In the preferred embodiment, the pump can be used for five distinct types of 
medicinal fluid infusion. Tables 1 through 5 show the variom parameters that are 
entered to define the protocol used to control the pump for each type of infusion. 
The parameters can selectively be set to read in units of ml, mg, or ^g. 
5 TABLE 1 

CONTI>aJOUS ONLY 



PARAMETER 


RANGE/COMMENT 


Rate 


0.1 ml/hr - 400 ml/hr 


Container Size (Total Volume) 


0.1 ml -9999.9 ml 


Air-in-line Alann Sensitivity (Hi, Low, Off) 


Hi (Bubbles > 73 ^l nominal) 
Low (Bubbles > 250 ^1 nominal) 
Off" (Bubbles > 2 ml nominal) 


TABLE 2 
PARENTERAL NUTRITION 


PARAMETER 


RANGE/COMMENT 


Container Size (Total Volume) 


1ml -9999 ml 


All Combinations of: Taper Up, lapa Down, 
& Continuous 


Taper is a gradually increasing or 
decreasing delivery rate 


Parenteral Nutrition Volume 


1 ml - 9600 ml 


Total Time for Infusion 


1 min to 24 hr 


Time Interval for Taper Infusion (If Selected) 


1 min to 3 hr 


Air-in-line Alami Sensitivity (Hi, Low, Off) - 
Optional 


Hi (Bubbles > 75 ^l nominal) 
Low (Bubbles > 250 nominal) 
Off (Bubbles > 2 ml nominal) 


Keep Vein Open (KVO) - Optional 


1 ml/hr - 5 ml/hr 



Parenteral Nutrition provides infusion of nutrient fluids that are necessar>' 
when a patient is unable to eat food, for example, because of problems with the 
gastrointestinal system. The rate at which the nutrient solution is infused can be 
programmed to taper up or down, or to continue on a continuous basis, or any 
30 combination of these three variables. The KVO option ensures that sufficient fluid 
is infused between programmed infusions to prevent blood clots from fomung in 
the vein or in the catheter through which the fluid is infused. 
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TABLES 
PAIN MANAGEMENT 



PARAMETER 


RANGE/COMMENT 


Select Delivery Mode 


Bolus, Continuous, or Combo 


Container Size (Total Voltnne) 


0.1 ml -9999.9 ml 


Rate 


0.1 ml/hr- 25.0 ml/hr 


Size of Bolus (If Bolus Delivery Mode is Used) 


Up to 25 ml (5 ml if subcutaneous 
infusion) - or subject to Limits 


Bolus Lx>ckout Of Bolus Used) 


5 min - 999 min (Time Between 
Boluses) 


Iniusion Site and Rate Limits at Each 


Intravenous or Epidural: 25 ml/hr 
Subcutaneous: 5 ml/hr 


Loading Dose (Clinician Administered Bolus) 


Not subject to Lockout, but subject 
to Limits 


Limit Number of Boluses Administered 


For example, 2 boluses/hr 


Four Hour Volume Limit 


Max. total volume in 4 hr period 


Subcutaneous Limit 


5 ml/hour of Drug Delivery 


Air-in-line Alami Sensitivity (Hi, Low, OS) - 
Optional 


Hi (Bubbles > 75 ^il nominal) 
Low (Bubbles > 250 ^1 nominal) 
Off (Bubbles > 2 ml nominal) 



Since pain management often enables patient controlled bolus infusion 
of pain killing drugs, this type of infusion protocol enables the clinician to limit 
the bolus infusions in several ways. The size of each bolus is defined by the 
protocol, as are the minimum time between successive boluses and the number 

25 of bolus infusions per hour. A further limit is the total volume delivered during 
a four-hour period. Medical personnel can selectively deliver a bolus infusion 
or loading dose more frequently than allowed by the bolus lockout time, but are 
limited by the total volume delivered. The infusion site selected introduces a 
limit on the volume of the drug delivered to the patient, whether by bolus, 

26 continuous, or a combination of bolus and continuous infusion. 
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TABLE 4 
INTERMITTENT 



PARAMETER 


RANGE/COMMENT 


Container Size (Total Volume) 


0,1 ml -9999.9 ml 


Dose Size 


0.1 ml -9600.0 ml 


lune Interval for Delivery of Dose 


1 min-24hr 


T^Z m. . 11 Tut 11 ■■■111 It ■111 ■ am nmm Oj m^TXama TX _ I T T _ - 

i ime interval between btart ot Dose Deliveries 


Tune interval for deliveiy of dose vp 
to24hr 


KVO (Optional) 


0.1ni]/hr-Sml/hr 


Delayed Start Time (Optional) 




Air-in-Line Sensitivity (Hi, Low, Off) - 
Optional 


Hi (Bubbles > 75 ^1 nominal) 
Low (Bubbles > 250 ^l nominal) 
Off (Bubbles > 2 ml nominal) 



The Intermittent type of infusion is often used to administer antibiotic 
15 therapy. Based on the two time intervals and the dose size» the control determines 
the appropriate rate of delivery. 

TABLES 
VARIABLE 



PARAMETER 


RANGE/COMMENT 


Container Size (Total Volume) 


0.1 ml -9999.9 ml 


Phase Program: Enter Start Time. Stop Time, 
&Dose 


1 - 12 Phases 

Chemotherapy - limited to 24 hr 
(One Phase Program required) 


Optional Base Rate: Enter Start Time, Stop 
Time. & Rate 


Rate: 0.1 ml/hr-400ml/hr 


Optional Bolus Dose (with Lockout Time) 


Up to 25 ml 


KVO (Optional) 


0.1 ml/hr-5ml/hr 


Air-in-line Alarm Sensitivity (Hi, Low, Off) 
- Optional 


Hi (Bubbles > 75 nl nominal) 
Low (Bubbles > 250 ^l nominal) 
Off (Bubbles > 2 ml nominal) 
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The Variable type of infusion, which is typically used to administer 
chemotherapy, requires that at least one phase program be entered, by selecting the 
start and stop times, and the dose. In addition, an optional base rate infusion can be 
added to the protocol by selecting the start time, stop tfane, and rate. 
5 In FIGURE 3, the steps required to enter parameters for use in controlling 

the pump to mfiise a medicinal fluid are illustrated, beginning at a start block 80. In 
a block 82, the operator indicates that a new protocol is bemg selected. 
Specifically, the operator depresses button 60 and selects "NEW PROGRAM," 
indicating that the protocol is to be changed. In response, the control for pump 50 
10 prompts the operator to select the type of infusion desired and then prompts the 
operator to enter each of the protocol parameters for the selected type of mfusion, 
one at a time, as indicated in a block 84. The various parameters that can be 
controlled by the operator in defining the protocol are noted in the preceding tables 
and depend upon the type of infusion selected. In addition, the operator can select 
1 5 the units that will be used for the parameters in defining the protocol. 

In a block 86, the protocol defined by the operator is shown on display 1 8 so 
that the operator can review it. Assuming that it is correct, in a block 88, the 
operator initiates the protocol to run by depressing START key 72. As indicated in 
block 88, this step initializes tiie pump for delivery of the fluid to be infused from 
20 the source container. When the control initializes, it zeroes out any prior values in 
memory and builds a control table based upon the protocol entered/selected by the 
operator. In a block 90, the pump delivers the fluid to the patient, in accordance 
with the parameters comprising the protocol. A decision block 92 determmes if a 
different protocol is required, based upon the operator depressing tiie CHANGE key 
25 and selecting "NEW PROGRAM," or alternatively, selecting "NEW 
CONTAINER" to repeat the previous protocol, as provided in a block 94. 

To repeat the current protocol, the control logic returns to block 88. 
However, if the operator indicates that a different protocol should be used, the logic 
proceeds back to block 82. The operator is tiien requested to indicate which new 
30 protocol is to be initiated, leading to die entr>' of each parameter employed for 
controlling tiie pump for that protocol. It should be evident tiiat each time a new 
protocol is entered in this manner, die operator may inadvertentiy enter an incorrect 
parameter, which may result in an error in die delivery of medicinal fluid to tiie 
patient. Furthermore, entry of the parameters required to define a protocol each 
35 time tiiat a different protocol is required is both inefficient and time consuming. 
Accordingly, the present invention provides an alternative. 
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Turning to FIGURE 4, control of the pump using a speed protocol that was 
previously entered is illustrated. The logic begins at a start block 100. Thereafter, 
in a decision block 102, the operator determines if a new protocol should be 
entered, i.e., whether the medicinal fluid currently being infused is one for which a 
S stored protocol is not available. If the protocol required to infuse the current 
medicinal fluid is already stored in RAM 37 as a speed protocol, the logic proceeds 
to a block 104 wherein the required speed protocol is recalled from memory. 
However, if the protocol required for infusing the current medicinal fluid is not 
available among the three protocols that are stored, the logic proceeds to a 

10 block 106, which requires that the operator enter the protocol parameters one at a 
time as explained above in connection with FIGURE 3. 

After either a stored speed protocol is recalled from memory, or a new 
protocol is entered, the logic proceeds at a block 108, enabling the operator to 
review the protocol on display 18. Thereafter, a block 110 provides for initializing 

15 the pimip for delivery of the fluid in accordance with the protocol, as indicated in a 
block 112. At any time, the operator may determine that a different protocol is 
required, as indicated in a decision block 114. Once the current protocol is 
completed, the operator may optionally repeat the protocol in accord with a 
block 116, entering the logic stream at block 110, or indicate that a different 

20 protocol is required, leading back to decision block 1 02. 

It should also be noted that the current protocol can be assigned to a speed 
protocol at any time after the protocol is manually entered, i.e., after block 106. 
Once assigned to a speed protocol, the protocol can be reviewed without affecting 
the current operation of the pump under control of a different protocol. Due to 

25 design limitations, only three speed protocols are stored at one time in the preferred 
embodiment. Accordingly., if the current protocol is assigned to a speed protocol, it 
will replace one of three existing speed protocols stored in memor>'. If less than 
three speed protocols are stored, the current protocol can be stored as an additional 
speed protocol without replacing any other stored speed protocol. 

30 The steps involved in assigning the parameters entered as a current protocol 

to a speed protocol are illustrated in FIGURE 5« beginning at a start block 120. In a 
block 122, the operator again indicates that a new protocol is to be entered. 
Thereafter, as provided in a block 124, the operator is prompted to select the type of 
infusion and to enter the protocol parameters one at a time. Once the parameters 

35 have been entered, they are presented on display 1 8, enabling the operator to review 
the protocol as indicated in a block 126. The operator may change any of the 
parameters comprising the protocol, using the BACKUP key to return to the input 
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screen. Display 18 can show three parameter lines at one time. A fourth line 
displays a prompt message to the operator, guiding the operator to carry out each of 
the steps necessary to review the protocol parametos. 

In a block 128, the operator assigns the current protocol just reviewed in 
5 block 126 to a selected qjeed protocol. To designate the speed protocol to which 
the current parameters are to be assigned, the operator presses the OPTIONS key, 
selects "SPEED PROTOCOL" from the menu on the display, selects "RECALL," 
and enters a speed protocol number (1 through 3), as indicated in a block 130. The 
control then determines if the number entered by the operator is akeady assigned to 
10 an existing speed protocol in a decision block 132. If so, the control causes the 
display to present a warning to the operator in a block 134, noting that the selected 
number is assigned to an existing speed protocol. At this point, the operator can 
cancel the assignmait of the speed protocol parameters to the selected number, 
enabling the previous speed protocol to be retained. However, if the operator elects 
15 to proceed with the replacement of the previous speed protocol that was assigned to 
the selected number, or if an existing speed protocol was not previously assigned to 
the number selected by the operator, the logic proceeds to a block 136. In 
block 136, the current program parameters are copied into memory, linked to the 
speed protocol number selected by the operator. The logic then exits at a block 138. 
20 If the operator determines that a medicinal fluid is to be infused into a patient for 

which a previously stored speed protocol can be used, the steps involved in recalling the 
speed protocol for use are implemented, as shown in FIGURE 6. From a start 
block 140, the logic proceeds to a block 142 in which the operator selects a menu 
(displayed after the OPTIONS key is depressed and "SPEED PROTOCOL" is 
25 selected), which reads "RECALL." Assuming that the operator has selected this option, 
the control prompts the operator to enter a speed protocol number, as indicated in a 
block 144. A dedsiwi block 146 then detennines if the speed protocol number entered 
by the operator in accordance with the logic of block 144 coiresponds to that of an 
existing speed protocol. If the response to decision block 146 is negative, the control 
30 displays a warning to the operator indicating that the selected speed protocol number 
does not correspond to one stored in memory, as noted in a block 148. The logic then 
proceeds to exit, as provided in a block 156. 

An affirmative response to decision block 146 leads to a block 150, wherein 
the selected speed protocol is copied into the current protocol for use in 
35 administering the medicinal fluid to the patient. At that point, the control causes the 
parameters of the now current protocol to be displayed to the operator for review, as 
indicated in a block 1 52. It should be noted that a speed protocol must be reviewed 
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before it is implemented as the current controlling protocol to insure that the 
operator does not inadvertently apply an inappropriate protocol to administer a 
specific medicinal fluid. After the review is completed, in a block 154, the control 
initializes the pump for deliveiy of the medicinal fluid in accordance v^th the 
5 parameters of the now current speed protocol, which was just recalled from 
RAM 37. The procedure then exits in block 156. 

At times, an operator may wish to delete a speed protocol that is stored in 
memor}\ The steps required to carry out the deletion are illustrated in FIGURE 7, 
beginning with a start block 160. In a block 162, the operator presses the 

10 OPTIONS key, selects "SPEED PROTOCOL'', and selects an option labeled 
"DELETE*' from the menu in display 18. In a block 164, the operator is prompted 
to enter the speed protocol number that is to be deleted. The control then 
determines whether the number entered by the operator corresponds to a stored 
speed protocol in a decision block 166. If not a block 168 provides for displaying a 

15 warning to the operator, indicating that the operator has selected a non-valid speed 
protocol number for deletion. Thereafter, the logic proceeds to a block 176, where 
it exits from this procedure. 

Assuming that the operator has entered a valid speed protocol number for 
deletion, the logic proceeds from decision block 166 to a block 170, which displays 

20 the type of protocol or inflision corresponding to the speed protocol number entered 
by the operator. The operator is then presented with the option of confirming the 
deletion (within the menu of display 18). If the operator dechnes to confirm the 
deletion of the selected speed protocol, the logic exits at block 1 76. However, if the 
operator confirms that the selected speed protocol should be deleted, the logic 

25 proceeds to a block 174. wherein the speed protocol is cleared from memory in 
RAM 37 by the control. Thereafter, the procedure concludes at block 1 76. 

Since the operator may not be familiar with each of the speed protocols 
stored in memory, provision is made for reviewing a selected speed protocol. This 
procedure, which can be elected at anytime without any effect on the current 

30 protocol being implemented to control the pump, is shown in FIGURE 8, beginning 
with a start block 180. In a block 182, the operator is presented with an option in 
the menu displayed that reads "REVIEW.'* Once this option is selected, the logic 
proceeds to a block 184 in which the operator is prompted to enter the speed 
protocol number for the speed protocol that is to be reviewed. The control then 

35 determines if the number entered by the operator corresponds to a stored speed 
protocol in a decision block 186. If not, the control displays a warning to the 



SffisinDiiflBr/Miirmt 



wo 96/20745 



-16- 



PCTA)S96/00431 



operator in a block 188, indicating that an invalid speed protocol number has been 
entered and then proceeds to a block 192, to exit the procedure. 

Assuming that the operator has entered a valid speed protocol number, a 
block 190 provides for displaying the selected speed protocol in the review format 
5 within display 1 8. This review fotnnat identifies the type of the speed protocol (i.e., 
the type of infiision) and any other parameters specific to that speed protocol. Once 
the operator has concluded reviewing the selected speed protocol, the logic exits in 
block 192. 

Finally, the operator can selectively print a copy of any of the speed 

10 protocols through a serial data link (not shown) on pump 50. Beginning at a start 
block 200, the operator is presented with a menu option labeled "PRINT," as 
indicated in a block 202. Thereafter, the operator is prompted to enter the speed 
protocol number that is to be printed, as indicated in a block 204. Once the speed 
protocol number is entered, the control transmits the data in the review format to an 

15 external printer (or to a computer coupled to a printer) through an RS-232 port, 
which is disposed on the bottom of the pump. In the event that the operator has 
selected a speed protocol number that is not assigned to any speed protocol stored 
in memory, the control prints the notation "NOT ASSIGNED." Following the logic 
in block 206, the procedure exits, as provided in a block 208. 

20 As will be evident from the foregoing disclosure, the use of stored speed 

protocols enables the operator to selectively infuse any medicinal fluid for which a 
stored speed protocol is appropriate wthout the need to reenter the parameters that 
control the pump during the infiision process. As a result, the likelihood of errors 
that might be introduced when reentering the parameters is decreased. More 

25 importantly, the operator is saved the trouble and time required to reenter 
parameters necessary to define protocols that are consistently used for infiising 
medicinal fluids, if the required protocol is among those stored in memory. By 
providing additional memor>', the preferred embodiment disclosed above can 
readily be modified to enable more than three speed protocols to be stored. 

30 Although the present invention has been described in connection with the 

preferred form of practicing it. it will be understood by those of ordinary skill in the 
art that many modifications can be made thereto within the scope of the claims that 
follow. Accordingly, it is not intended that the scope of the invention in any way be 
limited by the above description, but that it be determined entirely by reference to 

35 the claims that follow. 
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The invention in which an exclusive right is claimed is defined by the 
following: 

1 . A pump for administering a fluid to a patient, comprising: 

(a) a fluid drive unit that is adapted to couple with a fluid line 
and to force fluid from a source to the patient through the fluid line; 

(b) a control that is coupled to the fluid drive unit to control its 

operation; 

(c) a memory in which a plurality of protocols are stored, said 
protocols each specifying at least one parameter used to control the fluid drive; and 

(d) a user interface that is integral with the pump and is coupled 
to the control and to the memory to enable the operator to enter said at least one 
parameter for any of said plurality of protocols and to select one of said plurality of 
protocols for use by the control in actively controlling the operation of the drive unit 
so as to administer the fluid to the patient in accordance with said protocol that is 
selected. 

2. The pump of Claim 1, wherein the parameter comprises one of a 
continuous fluid flow, an intermittent fluid flow, and a bolus fluid flow. 

3. The pump of Claim 1, wherein the parameter comprises one of a rate 
of fluid flow, a volume of fluid flow, a time of fluid flow, and a duration of fluid 
flow. 

4. The pump of Claim 1 . wherein the user interface enables the operator 
to define a current protocol and to store the current protocol as one of the plurality 
of protocols in the memory. 

5. The pump of Claim 1, wherein the control cooperates with the user 
interface to enable the operator to review one of the plurality of protocols stored in 
the memory while the drive unh is being operated in accordance with a different one 
of the plurality of protocols. 

6. The pump of Claim h wherein said at least one parameter comprises 
a varying rate of fluid flow. 
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7. The pump of Claim 1 , wherein the user interfece enables the operator 
to recall one of the plurality of protocols from memory as a currently active protocol 
used by the control in controlling the drive unit, and enables the operator to modify 
said currently active protocol prior to storing it in the memory. 

8. A pump for administering at least one medicinal fluid to a patient 
through a fluid line, said pump comprising: 

(a) a microprocessor controller responsive to program steps 
stored in a memory associated with the microprocessor controller, said program 
steps effecting control of the pump in accordance with an operator selected 
protocol; 

(b) a fluid pumping unit for forcing fluid into the patient through 
the fluid line, said fluid pumping unit being electrically coupled to the 
microprocessor controller and controlled thereby; and 

(c) a control panel that is electrically coupled to the 
microprocessor controller, integral with the pump, said control panel including a 
display and a plurality of switches that enable an operator to select parameters used 
to define each of a plurality of protocols that are stored in the memory, said 
switches also enabling the operator to recall one of the plurality of protocols as a 
current protocol for controlling the fluid pumping unit. 

9. The pump of Claim 8, wherein the microprocessor controller enables 
the operator to review parameters for one of the stored protocols while using a 
different protocol to control the fluid pumping unit. 

10. The pump of Claim 8, wherein the parameters that define the 
plurality of protocols comprise at least one of a fluid flow rate, a fluid volume, a 
duration for fluid flow through the pump, and a time to initiate fluid flow through 
the pump. 

11. The pump of Claim 8. wherein the parameters that defme the 
plurality of protocols comprise at least one of a parenteral nutrition fluid delivery, a 
pain management fluid delivery, an intermittem fluid deliver)', a variable time fluid 
deliver)-, and a continuous fluid deliver)'. 

12. The pump of Claim 11, wherein the parenteral nutrition fluid 
deliver)' comprises an operator selected parameter for at least one of a continuous 
fluid flow, and a continuous fluid flow with a tapering fluid flow rate. 
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13. The pump of Claim 11, wherein the pain management fluid delivery 
comprises an operator selected parameter for at least one of an intravenous fluid 
administration, an epidural fluid administration, and a subcutaneous fluid 
administration. 

14. The pump of Claim 11, where the variable time fluid delivery 
comprises an operator selected parameter for at least one dose designating at least 
one of a percent£^e of volume, a rate of flow, and a volume. 

15. The pump of Claim 8, wherein the program steps enable the operator 
to print a selected protocol while the pump is administering the fluid in accordance 
with a different protocol. 

16. The pump of Claim 8, wherein the parameters selected to defme the 
plurality of protocols include a keep vein open fluid flow rate option. 

17. The pximp of Claim 8, wherein the parameters selected to defme the 
plurality of protocols include a bolus injection option. 

1 8. The pump of Claim 8, wherein the program steps enable the operator 
to recall one of the pltvality of protocols as a current protocol and to modify said 
current protocol by changing at least one of the parameters that define it. 

19. The pump of Claim 8, wherein the program steps provide prompts to 
the operator on the display that indicate the parameters that are selectable by the 
operator. 

20. The pump of Claim 19, wherein the prompts indicate a plurality of 
units of measurement to enable the operator to select the units of measiu^ment for at 
least one of the parameters that define the plurality of protocols stored in the 
memor\'. 

21 . The pump of Claim 8. wherein the program steps require that any of 
the plurality of protocols recalled firom memory be reviewed by the operator before 
the fluid pumping unit is controlled with said protocol. 

22. The pump of Claim 8, further comprising a backup battery power 
supply to maintain storage of the plurality of protocols in the memory when the 
pump is disconnected from another source of power. 
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